Personally I dislike this feature because you'll lose all customization on subtitles when they are burned into the video. I'd rather look into what causes the subtitles to be out-of-sync. There's a possibility (although small) that it is already fixed in the master branch after #4455 was merged.
If we have a better understanding of what causes the sync issues and determine it is not (easily) fixable we can always look into the burning option again.

Personally I dislike this feature because you'll lose all customization on subtitles when they are burned into the video. I'd rather look into what causes the subtitles to be out-of-sync.

To quote my comment on the related issue here:

From what I understand, subtitle sync issues during transcoding are a problem that's not easy to solve and a new option was introduced in Jellyfin 10.10 to help out people who are affected. (jellyfin/jellyfin#2547 (comment), jellyfin/jellyfin#12430).

Subtitles often have synchronization issues after video transcoding. This option allows the client to opt-in to always burn in all subtitles, preventing out-of-sync subtitles at the cost of transcoding performance.

The option is already implemented in jellyfin-web where I tested it out and (for me at least) it solved the sync issues I was seeing when transcoding.

Now, I don't know much about Jellyfin's internals, I've been using it for a bit more than a year but this is the first time I'm exploring the code. But to me it sounded like this is an issue on the server that is unlikely to get solved in the short run which is why you/they are offering this workaround. I might be wrong about that, so I'll also tag @gnattu who may be able to explain this better than I can.

I do understand and appreciate your concerns about customization on subtitles, but I do think most users would prefer losing that over not being able to understand what's being said in their videos.

If a fix for these sync issues was on the horizon, I would also want to push that through over adding a workaround, but it doesn't look like that to me. As things stand, and if it is indeed a server issue, I'd even consider this PR to be adding a missing feature to improve feature parity.

I should probably have gotten involved earlier, reporting this at least, but I would be remiss not to add I've had this problem from the day I started using Jellyfin and have just been lucky that up until now my client and network have always been capable of direct playing anything I threw at it.

There's a possibility (although small) that it is already fixed in the master branch after #4455 was merged.

No, it didn't fix this (for me), I tested if the issue was still present on master before I started on this PR.

If we have a better understanding of what causes the sync issues and determine it is not (easily) fixable we can always look into the burning option again.

Maybe @gnattu will be able to shed some light on that but if there is anything I can do in regards to testing, do please let me know.

It is indeed a problem that is hard to track down. Neither Emby nor Plex provided full solution to this yet. The transcoding is a very complex process and the time codes can change during that process, and sometimes it would be larger enough to make the original subtitles to look very off with the original time codes. You might even notice that the transcoded video can have a different video duration that is longer/shorter than the original one, and sometimes even the actual fps is slightly modified (like 29.97 being speeded up to 30). There are too many reasons that the time code might being altered and that is why I implemented that brute force hack as a workaround.

Is it bad? Yes. And the way it is implemented is also very hacky. Because we don't have a good API to determine the actual playback method before the playback has started (the one returns before the playback does not differ transcode and remux and both will be reported as remux), the is transcoding is detected after the playback has started using the api to check for playback stats, and then determine should the client load the subtitle or not to prevent double-subtitles.

Allowing burn-in subtitles when transcoding would also help mitigate this problem, since the burned in subtitles don't overlap like exoplayer does: #4522

The option would be useful even when transcoding is for audio only (TV app: subtitles will go out of sync if you are downmixing audio and you interrupt things by seeking, in either direction).

Fixing the root issues would be preferrable but seems difficult and, until then, having the option to force burn-in would really help

Hey @nielsvanvelzen, this PR has a merge conflict and I'd rather not rebase if the answer is going to be no, so I'm checking in.

I've done some more testing and research since we last spoke:

• Still reproducible: I can confirm the subtitle desync is still present on the latest stable (server 10.11.6, Android TV 0.19.7) as well as on the latest unstable server build. External SRT subtitles desync after seeking during transcoding. Burn-in fixes it every time.
• I was hopeful it was fixed on jellyfin's main branch when I saw these, which is why I tested unstable too. (noaccurate_seek breaks subtitle synchronisation jellyfin#15845 identified -noaccurate_seek as a cause and PR Refactor HLS transcode seeking jellyfin#15926 removes it during transcodes.) However, even on unstable with that fix applied, the desync still occurs, confirming @gnattu's earlier point that there are likely multiple causes for the timecode drift.
• I saw the Roku client shipped this option too, if that matters (Burn subtitles if transcoding. Force Transcode option updated to disallow remux. jellyfin-roku#511)
• It doesn't sound like an upstream fix is on the horizon right now (going from previous comments here)

This is an opt-in toggle. Users who don't need it won't be affected, and users who do currently have no way to get working subtitles during transcoding on Android TV.

Are you open to merging this, or should I close it?

Ok after reconsidering I'm still not the biggest fan of this as it will prevent the subtitle customization from working. But I also understand that some people would be fine with that trade off when it "solves" the synchronization issue. Therefor I think it's fine to add a setting for this in the advanced playback preferences with at least a heads up about it ignoring the customization options in the description.

@GertSallaerts if you can fix the merge conflicts we can go ahead and merge this.

@nielsvanvelzen rebased on the master branch

Thanks for working on this!